Skip to main content
This page explains how to prepare requests and payloads for the API. The exact schema is endpoint- and release-specific; obtain required fields, validators, enums, and nested object shapes from the controller/service/DTO or validation code in the target checkout.

Request format

For JSON endpoints, send Content-Type: application/json and a valid JSON body. Use the HTTP method and path shown by the API documentation generated by the running application or verified route registration.
The JSON above is a format illustration, not a valid SpurtCommerce endpoint contract.

Payload preparation checklist

  • Include only fields accepted by the target endpoint.
  • Match the expected primitive types and enum values.
  • Distinguish omitted fields from explicit null, false, zero, and empty strings.
  • Use database identifiers returned by the API, not display labels, unless the schema explicitly expects a label.
  • Respect tenant/application scope where required.
  • Validate nested arrays and objects against the endpoint’s DTO or validation logic.
  • Do not send server-managed timestamps, totals, ownership fields, or status transitions unless the API explicitly permits them.

Multipart payloads

File endpoints may require multipart/form-data rather than JSON. Use the exact form field name from the upload controller and do not manually set the multipart boundary in browser clients.

Validation and errors

Send one invalid field at a time in staging to understand validation behavior. Record the HTTP status, error code/message, and correlation/request ID. Never include real passwords, tokens, card data, or customer personal data in examples.

Source verification

Search src/api/controllers, related services/models, and validation middleware for the route. Compare the implementation with the generated API documentation and a successful staging request before publishing a concrete schema.